Repository navigation
Conversation
Compaction loop follow-upHeads-up: this fix is correct and should not be blocked, but it can expose a pre-existing runaway compaction loop on sessions that already accumulated many summary messages. I reproduced it on a real session after applying the equivalent change locally: 139 summary system messages (~1.25M chars), a new summary every 30–60 seconds, and later summaries degenerating into "transcript truncated / no user turns". The loop is in I opened #383 with the evidence, a minimal reproduction, and suggested guards (merge/prune summaries, include them in the compactable range, or stop after one compaction when |
Problem - Conversation compacting is crashing!
When a session contains images,
getCompactPrompt()serializes every message'scontentParamsverbatim. Inline image content is stored asdata:image/...;base64,..., so the summary request counts the raw base64 payload as text tokens.A real session with 18 screenshots in the summarized range contained about 2.5 MB of base64 data. The compaction request was 2,135,942 tokens against a 1,048,576-token model limit, so it failed with HTTP 400. Because compaction aborts before marking any messages as compacted, the session was permanently stuck above the auto-compaction threshold and could not continue.
Normal chat requests are unaffected because they send images as
image_urlparts, which are counted as image tokens rather than text.Fix
data:image URLs with[image data omitted from compaction prompt]when building the summary prompt.detail).contentParamsuntouched.Verification
node --import tsx --test src/tests/prompt.test.ts— 25/25 passtsc -p ./ --noEmit— passeslinton changed files — passprettier --checkon changed files — passThe 3 failures are permission tests (
computeToolCallPermissions,UnderstandImage,ReadImage). They also fail on a clean checkout ofHEADand are unrelated to this change.